1. Field of the Invention
This invention relates to the creation and validation of software applications intended for execution by an interpretive virtual machine.
2. Description of the Prior Art
Computers and computing devices have become a ubiquitous aspect of modern life. In the 1960s and '70s, a computer was a room-sized mainframe which ran a few specialized programs for business or scientific applications. The introduction of the personal computer in the 1980s began to change the perception and use of the computer—thousands of applications were created to serve a wide variety of commercial, business, educational and entertainment functions. More recent advances in semiconductor technology allow computing power to be incorporated into an ever-expanding array of other consumer devices—telephones, automobiles, kitchen appliances, personal digital assistants, and television receivers. The current invention, while focused on the last category, has broader applicability to this range of non-traditional computational systems.
Conventional analog television broadcast is being superceded by digital encoding and broadcast. This development has several promised benefits, including greater picture fidelity and higher audio quality. A prerequisite for successful digital reception is a computing engine capable of receiving, decrypting, decoding and displaying the digitized television video and audio signals. The computation requirements for the various sub-functions are highly asymmetric—the decoding function in particular requires specialized computational hardware, but the other functions can be performed by conventional microprocessors. In fact, contemporary microprocessors are sufficiently powerful that significant surplus computational capability is available beyond the relatively simple functions of managing or performing reception, decryption and display. Accordingly, digital television receivers (often called set-top boxes or STBs) are provided with the capability for reprogramming, for executing custom applications provided to the STB via the broadcast stream or other means. In some ways, the STB is just another computer in the household available for useful or entertaining computational work.
In some very significant ways, however, the STB is unlike the typical PC. In the early days of cable, the cable box was supplied by the cable system provider, and was rented by the viewer through a monthly payment often buried in the cable bill. The viewer did not, and generally could not, purchase a cable receiver. Eventually as cable spread, televisions and video recorders began to incorporate ‘cable-ready’ capabilities. But as long as the cable provider was supplying the cable box, economics dictated utilizing the installed boxes as long as possible to maximize return (since maintenance was generally negligent). As digital cable becomes available, the same market dynamic is being applied.
The STB is an appliance, and like the television set it accompanies, is perceived to have a relatively long useful life. An eight-year-old computer is generally considered nearly useless—an eight-year-old television set (or cable box) is not. Computer capabilities and standards change rapidly and continuously, while television standards do not. The PC is purchased by the consumer, who shops for features and price, whereas the STB has traditionally been supplied by the cable operator, who dictates features and price. The consumer of an STB or satellite receiver is generally interested in entertainment, and has not to date been enticed by enhanced capabilities of interactivity provided by one platform versus another.
Thus an enormous economic incentive exists for the cable provider to maximize the lifetime and utility of installed STBs. As computer components and systems have become more powerful and less expensive, these capabilities have been built into newer model STBs, but legacy boxes remain in use and will continue to be supported until appropriate economic factors dictate their replacement.
The continuing utilization of legacy STBs becomes of particular relevance when considering the evolution of software languages used in digital receiver systems. In general computing, scores of software languages have been created since the first digital computers were introduced. Each had some benefit or utility which justified its development. Some languages were appropriate only to a single machine or system architecture, while others were intended to be appropriate over a broad, or universal, range of computational platforms. Languages come and go; the software community sense of what language is most useful or appropriate changes over time, and languages are not static. Today, web development uses the HTML standard, but the more recent XML standard will likely supercede HTML and become the future standard. HTML is often supplemented by additional algorithm functionality; initially this was provided by JavaScript, but various browsers also support Visual Basic, Java, and most recently .NET.
This evolution of languages is seen in the STB hardware/software arena as well. To reduce costs, cable providers fostered competition among STB manufacturers, allowing various hardware designs to support a common application language. Various application languages, commonly called middlewares, were developed, each supported by a variety of hardware configurations. Because the technology built from the bottom up, there were no standards for these middlewares, and features and capabilities varied widely. Each middleware developer created proprietary tools for coding applications, and the quality of these tools also varied widely. Learning to use the tools and to craft applications for a particular middleware required significant investment, and the cost of application development was high, even for a single middleware. Because of the disparities among the systems, each separate middleware required duplicate investment of time and effort, so that development and proliferation of interactive television (ITV) applications was slow and costly.
Recognizing these problems, industry representatives began to press for standard development languages and systems. These efforts took two directions. First, standards were developed which intended to provide interactivity on even the simplest and least capable platforms. The Multimedia Hypermedia Experts Group (MHEG) standard is an example of such a standard. However, the limited capabilities of this standard, and its arcane nature, have prevented widespread use. The second direction was to select a common development language and feature set for future platforms. The Java language is a popular medium for programming in a distributed and heterogeneous computing environment and is by its nature well suited to development for embedded systems. Thus Java became the basis for two of these emerging ITV specifications, the Digital Video Broadcast-Multimedia Home Platform (DVB-MHP) and Open Cable Application Platform (OCAP) standards. Java source code is compiled to a common byte-code format which can be interpreted on a wide variety of platforms. By the addition of appropriate television-specific objects and functions, Java can provide a fully-featured execution vehicle for ITV applications.
The use of Java as the development and execution language does however bring significant costs. The complexity of the language requires significant memory, and acceptable levels of performance require significant computation power in the platform. Both of these requirements obviate the use of Java as a solution to the problem of legacy STBs, since memory and CPU capabilities are well below the minimum requirements, and upgrades are infeasible. Thus, while Java may unify application development for future STBs, it does not impact the problem of practical ITV application development and deployment to legacy boxes.
What is desired is a software language, with an associated development and execution environment, which can support the development of ITV applications on both legacy and future digital television platforms, which takes advantage of the variety of capabilities of these platforms without limitation to the lowest common level of service provided by all platforms. Additionally, the language and associated development tools must support display and evaluation of the developed applications and ultimately work with the potential multiplicity of target systems.